Problem

c3_shell._run_sync used subprocess.Popen(shell=True), which on Windows resolves to cmd.exe via COMSPEC. But the rest of the environment — the native Bash tool, CLAUDE.md conventions, and agent command habits — speaks POSIX via Git Bash. So any bash-flavored command (ls/grep/cat, single quotes, $VAR, /dev/null, forward-slash flags, heredocs) silently failed under cmd.exe and forced a fall back to native Bash — defeating the purpose of c3_shell as a structured drop-in.

Reproduced live: echo "x" printed the quotes literally; a bash for loop returned f was unexpected at this time; a heredoc returned << was unexpected at this time — all classic cmd.exe behavior.

Fix

_run_sync now runs commands through Git Bash (bash -c) on Windows when a Git-for-Windows bash.exe is discoverable, matching the native Bash tool. cmd.exe remains the fallback when no bash is found.

• _discover_git_bash() — prefers Git install locations (ProgramW6432/ProgramFiles(x86) + literal C:\Program Files\Git\...) and PATH, and rejects WSL/Store bash (System32 / WindowsApps) whose /mnt/c path semantics would break cwd.
• _select_bash() — honors a new C3_SHELL_BASH override: 0/cmd/off/false forces cmd.exe; an existing file path forces that bash. Discovery is cached.
• POSIX platforms unchanged (shell=True → /bin/sh).

Verified live: the new code selected C:\Program Files\Git\bin\bash.exe, stripped quotes, and ran ls -d + /dev/null redirect at exit 0.

Tests

• New TestShellSelection (8 tests): non-win32 short-circuit, env-override (0 + explicit path), Git-Bash discovery, WSL/System32 rejection, and _run_sync argv routing (bash vs cmd.exe).
• test_c3_shell suite green (26/26); ruff check clean.

Version

Bumps to 2.41.0 (cli/c3.py, pyproject.toml) + CHANGELOG entry.

Note: takes effect for the live c3_shell tool only after the MCP server restarts.

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code